Some embodiments of the invention relate to technologies for automatically classifying defects and issues. Some embodiments of the invention relate to method(s), system(s), and computer program product for implementing automatic defect fixes upgrade expert assessment technologies. Some embodiments relate to method(s), system(s), and computer program product(s) for automatic classification of defects and/or issues of a piece of software, hardware, or a combination of software and hardware.
Various embodiments as disclosed below use computer program(s) and/or software application(s) as examples for illustration purposes. These examples are presented for the ease of explanation and illustration and do not intend to limit the scope of various embodiments of the invention.
During a typical development cycle of a product such as a piece of computer software, developers and/or programmers often fix errors, mistakes, faults, failures, flaws, bugs, or undesirable features (collectively defects) as they are found during the development or maintenance cycle and distribute the fixes for such defects in the form of new versions or releases of the software or patches. For the software development team, it may be desirable to know the patterns or trends of the defects. For example, the product development or maintenance team may also be interested to know whether the defect of interest. For example, such patterns or trends of defects may be used so as to prioritize various tasks in the development or maintenance of the software and properly allocate resources accordingly. Such patterns or trends of defects may also be used for reporting purposes. Another use of such patterns or trends of defects is for continuous improvement of the software product and for quality assurance.
In order to better access information or data related to these defects, the details, metadata, bug report(s), and/or diagnostic data about these defects are often stored in some forms of data structures such as in database(s), table(s), spreadsheet(s), or list(s) (collectively database). The members of the software development or maintenance team often track, open, investigate, fix, and then close such defects by accessing such a database. Nonetheless, such information or data related to these defects are often stored in an unstructured manner format in this type of database. Here, such stored information or data may be “unstructured” even though they may characterized as structured as is commonly understood where the structure of such stored information or data is not sufficiently helpful for the desired debugging and bug-fixing tasks. What further clutter the storage of such information or data is that such information or data are often stored with other types of administrative data. This would further reduce the usefulness of such “databases” for these defects.
Often, such information or data may comprise dates, snippets of log and trace files, comments of engineers or customers, error messages generated by the software product, responses from customers, etc. Therefore, the developers or programmers have to go through a lot of information or data in order to properly assess the impact of a defect. Nonetheless, the impact of a defect may encompass one and more often several functional areas. Therefore, the software development or maintenance team needs to categorize each defect so as to prepare the information or data received for analysis to better understand the patterns or trends of defects.
On the other hand, categorization or classification of defects often require a substantial amount of time and effort of one or more skilled programmers or engineers in order to better understand the impact of the defect of interest and/or what functional area(s) is (are) affected. As a result, engineers often manually categorize such defects. Such a manual process is not only prone to error but also wastes a lot of resources.
To further exacerbate the problem with the aforementioned manual process, for large software project, there may exist many such defects which need to analyzed and/or fixed. This further hinders the aforementioned manual process for categorizing the defects.
In addition, even if the aforementioned manual process were to be possible the result of the categorization may change over time as new defects are found which may change the patterns or trends that are previously determined based on old defects. Therefore, the engineers may be required to repeatedly perform successive passes over time in order to correctly categorize the defects and to generate correct patterns or trends of the defects of the software product. This requirement of repeated performance of successive passes thus renders the manual process of the defects even more unlikely.
In addition to the categorization and assessment of patterns or trends of defects, the fixes of the defects may often be incorporated into future releases of the products. The fixes of the defects may also be incorporated into one or more patches to provide the fixes to the current installed base which may be widespread among many customers using different versions of the product on different platforms such as some hardware like computers and/or concurrently running software like operating systems.
Similarly, as time elapses and new releases of the software product are released, customers of the current installed base may desire or may be encouraged to adopt new versions of the software product for various reasons. For example, the customers may decide to adopt the new releases to take advantage of the new features and functionality of the new releases. As another example, the customers may decide to adopt the new releases because the support or warranty for their existing versions may be expiring. Often, these customers may have already had patches applied to their current versions of the software product. These customers usually engage in upgrade planning where the customers decide to change to a newer version of the software product on possibly different platforms running possibly different operation systems from their current ones.
Such an upgrade planning is of critical importance because it may eliminate unnecessary downtime and loss of productivity. For the upgrade planning, the customers may need to be able to determine what patch(es) they have already installed. The customers may need to determine what defects have not been fix on their current installed base for which fixes are available in certain versions of the patch(es). The customers may also need to determine what defects are not fixed yet so no patch is available. The customers may also wish to know what defects have already been fixed in the desired releases on their target platforms running certain operating systems.
The customers may also wish to know what defects have been fixed, but there are currently no patches available for their current choice of platforms and operation systems. Note that patches for defects are often produced on an as needed basis and may not be uniformly available for all versions and platform/operation system at the same time. Generally, the more defects to be fixed the longer the lead-time may be. Also, the more combinations of platforms and operation systems to apply the patches to the longer the lead-time may be. This information may be important to the customers because there may be a lead-time associated with the requesting, building, and distributing patches to fix certain defects for a particular platform running a particular operating system. This lead-time information may be crucial for the customers' upgrade planning.
Currently, it is almost necessary for customers to submit their inventory of patches and perhaps context information in a form of a request such as a service request for a formal analysis or to some support personnel such as product support engineers or customer support engineers for an informal analysis to determine the status of patches in the target version(s) of the product(s) and the combination(s) of platform and operating system that the customers would like to adopt. A customer often considers one or more target versions of the product and one or more combinations of the platform and operating system as a part of the upgrade strategy. Nonetheless, the current formal analysis in response to a service request or informal analysis by the support personnel is time consuming and expensive. These analyses are also prone to human error, and the results are typically highly dependent upon the level of skills of the support personnel for, for example, interpreting possibly conflicting or ambiguous data regarding the availability of fixes and patches.
Therefore, there exists a need for a method, system, and computer program product for automatically classifying defects. There also exists a need for a method, system, and computer program product for analyzing and reporting patch status.